@stefanozampini when does BDDC need the coordinates? Only for H1?

It usually requires coordinates to identify enough subdomain corners so that the local Neumann problem is non-singular. So I would say every finite element space that associates dofs to element vertices

Alright, that is what I thought, hence the vdofs logic. But what about non-conforming spaces like Crouzeix-Raviart and Mardal-Tai-Winther?

I have never experimented with those elements. They are non-conforming, but they associate point evaluations right? So I would say each dof that is a point evaluation. Then I should probably check if the BDDC code can accepts NaNs for some of the coordinates and completely exclude the search from these dofs. This way, we can extract what we need only from point-evaluation dofs

CR has point evaluations at faces, but MTW is more like BDM plus tangential moments on facets.

I can always associate the dofs with entities and give you the coordinates of the entity

which is what you are doing in this PR? Leave it as it is then. There's no theory on this; the reason for doing this is practical. if your subdomain problem is just a seminorm (think Poisson), you need to exclude some dofs to get an invertible local Neumann problem. And this can be done with CG elements by just identifying subdomain corners dofs. The equivalent for Hcurl and HDiv problems is probably to identify the dofs on the faces/edges that represent the lowest-order moment, and pick at least one of them per subdomain edge/face (this is what I do using coordinates). But this is just speculation and I have never experimented much with that

@stefanozampini this test is currently failing (PCG diveges due to indefinite PC). You can run it with

pytest -vs tests/firedrake/regression/test_bddc.py::test_bddc_elasticity_aij_simplex -m parallel[1]

This should be an option, not always True

I would use numpy.isclose